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DD4hep serves as a generic detector description toolkit recommended for offline software development in 
next-generation high-energy physics (HEP) experiments. Conversely, Filmbox (FBX) stands out as a widely 
used 3D modeling file format within the 3D software industry. In this paper, we introduce a novel method that 
can automatically convert complex HEP detector geometries from DD4hep description into 3D models in the 
FBX format. The feasibility of this method was demonstrated by its application to the DD4hep description of 
the Compact Linear Collider detector and several sub-detectors of the super Tau-Charm facility and circular 
electron-positron collider experiments. The automatic DD4hep—FBX detector conversion interface provides 
convenience for further development of applications, such as detector design, simulation, visualization, data 


monitoring, and outreach, in HEP experiments. 
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I. INTRODUCTION 


In the realm of high-energy physics (HEP) software, with 
increasing detector complexity and data amounts in next- 
generation experiments, challenges arise from detector de- 
scription, high-performance computing applications, data 
processing, and analysis [1]. Detector description is an es- 
sential part of the HEP software across different stages of 
the lifetime of an experiment. It provides vital detector in- 
formation for various applications, such as detector design, 
optimization, simulation, reconstruction, event display, data 
monitoring, and physical analysis. 

The detector description toolkit for HEP (DD4hep) [2], a 
generic detector description toolkit, draws from the experi- 
ence of the detector description system development for the 
large hadron collider (LHC) experiments [3] and the linear 
collider community [4]. DD4hep provides consistent detector 
descriptions from a single source with minimal information to 
obtain the desired results for simulation, reconstruction, and 
analysis applications. This has been adopted in conceptual 
design studies on future high-energy colliders. 

FBX [5] is a well-known 3D asset-exchange format that 
facilitates high-fidelity data exchange. It is one of the most 
commonly used geometric modeling formats across various 
industries, supporting seamless sharing and utilization across 
various digital modeling and content creation programs. FBX 
finds extensive application across various domains, includ- 
ing visualization, video and multimedia development, game 
production, and enhancing functionalities within the realm of 
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virtual reality (VR) [6] and augmented reality (AR) [7]. Fur- 
thermore, the FBX file format, which uses surface modeling, 
offers an innovative approach for simulating detector mod- 
els. However, the direct conversion of the detector descrip- 
tion from DD4hep to FBX format remains available, hinder- 
ing the utilization of 3D software into HEP software develop- 
ment within the industry. 

In this study, we developed a method to automate the con- 
version of DD4hep detector description into the FBX for- 
mat, thereby bridging the next-generation HEP detector ge- 
ometry and visualization with industrial modeling. For HEP 
detectors that have been described using DD4hep in offline 
software, such as the Compact Linear Collider (CLIC), Fu- 
ture Circular Collider (FCC), circular electron-positron col- 
lider (CEPC), and super Tau-Charm facility (STCF) exper- 
iments, the interface could directly convert them into FBX 
formats. This advancements enables the further development 
and expansion of applications using industrial 3D software. 

The remainder of this paper is organized as follows: In 
Section II, we introduce detector description with DD4hep in 
HEP offline software, FBX 3D modeling, and their respective 
characteristics. Section II, presents the conversion method 
from DD4hep to the FBX format. In Section IV, we discuss 
its applications in the CLIC and other experiments, as well 
as its performance, and potential for further developments. 
Finally, Section Vprovides a summary of the results. 


Il. DETECTOR DESCRIPTION 


Currently, different types of detector geometry formats 
and libraries are used in HEP software toolkits, such as 
Geant4 [8], ROOT [9], and the geometry description markup 
language (GDML) [10]. Geant4 is a commonly used toolkit 
to simulate particle interactions with detectors, including the 
ATLAS [11] and CMS [12] detectors at the LHC [13] and 
Jiangmen Underground Neutrino Observatory (JUNO) [14]. 
ROOT has been used for detector description [15] in the 
sPHENIX [16] experiment at the relativistic heavy ion col- 
lider and in the design of the detector at the electron-ion col- 
lider in China (EicC) [17]. The geometry of Geant4 or ROOT 
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Fig. 1. Components of DD4hep detector geometry toolkit [28]. 


can be applied in the GDML format, which can also be im- 
plemented into the offline software of an experiment, as re- 
alized in the BESIII [18] experiment. DD4hep is a generic 
detector description technique driven by the HEP community, 
for applications in next-generation HEP experiments, such as 
CLIC [19], FCC [20], ILC [21], CEPC [22], STCF [23], and 
Muon Colliders [24, 25]. In addition, the Large Hadron Col- 
lider beauty (LHCb) experiment continues to develop from 
the geometry to the DD4hep toolkit [26]. 


A. DD4hep 


Future collider experiments require advanced software and 
computing techniques to optimize detector performance and 
maximize the physics capabilities. The design of detector 
hardware cannot be separated from the detector description 
in the offline software, which combines simulation and recon- 
struction to evaluate detector performance. A common detec- 
tor description solution benefits each experiment and save re- 
sources for software development. In the HEP software foun- 
dation (HSF) community White Paper [27] and the roadmap 
for HEP software and computing R&D for the 2020s [1], 
DD4hep was recommended for detector description in offline 
software for the next-generation HEP experiments. 

DD4hep provides a comprehensive detector description for 
the quantification of detectors and the necessary information 
for the interpretation of geometric data from experiments. 
The structure of DD4hep is shown in Fig. 1. DD4hep uses a 
pre-existing and widely used software combined with a con- 
sistent generic detector description. Its main components in- 
clude the ROOT geometry package for constructing and vi- 
sualizing geometry and the Geant4 simulation toolkit, which 
can interface via DD4hep to perform detector simulations for 
complex detectors. DD4hep is designed to operate indepen- 
dently of any Monte Carlo simulation engine. This method 
has the following advantages: 


e Complete detector description. It provides comprehen- 
sive information on detector geometry, materials, struc- 
tures, visualization attributes, detector readout infor- 
mation, alignment, calibration, and environmental pa- 
rameters. 


e Coverage of the full experiment life cycle. It supports 
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Fig. 2. Simple toy detector described with DD4hep and displayed in 
ROOT. 


Fig. 3. Half sphere described by the mesh in FBX. 


all stages including initial detector concept develop- 
ment, detector optimization, construction, and opera- 
tion. Additionally, it enables an easy transition from 
one stage to another with detector version control. 


Single source of information. It provides a consistent 
detector description for all applications including sim- 
ulation, reconstruction, event display, data monitoring, 
and data analysis. 


e Ease of Use. It provides a simple and intuitive inter- 
face, with minimal external dependencies. 


Fig. 2 shows a simplified example of the detector geometry 
description using DD4hep. The detector is visualized using 
the ROOT OpenGL display engine. 


B. FBX format 


FBX, or Filmbox, originally developed by Kaydara for 
MotionBuilder and acquired by Autodesk in 2006 [29, 30], 
is a 3D-mesh file format used to exchange 3D models and 
animation data. It shows potential for industrial applications. 
As shown in Fig. 3, FBX describes the geometric structure of 
objects using a mesh. FBX files are compatible with various 
scenarios and software platforms of unreal Engine, including 
3ds Max [31], Maya [32], Blender [33], Unity [34], and Un- 
real Engine [35]. FBX can store models, textures, lighting, 
animations, and special effects. It is often used in the video 
game industry for character assets and environments. 
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FBX has wide applications in 3D modeling and animation, 
extending to areas such as VR and AR. FBX files contain in- 
formation related to geometries, materials, animations, skele- 
tons, and other data, rendering them potential file formats. In 
Unity, FBX files can be directly imported for building game 
scenes, character models, and animations. They also supports 
detection and instance visualization, enabling developers to 
effectively understand and debug models and animations. 


C. Surface description 


The evolution of HEP depends on highly statistical physi- 
cal instances. With continuous progress in science and tech- 
nology, the demand for considerable data and high computing 
power in experimental physics research has increased. As an 
important part of experimental calculations, detector simula- 
tion requires considerable computational power to simulate 
the interaction and propagation of particles in a detector. 

A new technology is gradually being applied to de- 
tector simulation. In other words, graphics processing 
units (GPUs) are used rather than the traditional central pro- 
cessing unit (CPU) to achieve certain simulation functions. 
Compared with CPUs, GPUs have high parallel computing 
power and can process considerable amounts of data simulta- 
neously, thus accelerating the simulation process. The appli- 
cation of this technique is expected to improve simulation per- 
formance and reduce calculation time in future experiments. 

Furthermore, the structural description of a detector affects 
simulation performance. Traditional detector descriptions, 
including Geant4, ROOT, and GDML, rely on constructive 
solid geometry (CSG), which has limitations in GPU simu- 
lations. In contrast, a detector structure employing a polyg- 
onal surface description is suitable for GPU simulation be- 
cause it can efficiently use the parallel computing power of 
the GPU [36]. 

Therefore, one of the development directions for improv- 
ing the simulation performance of detectors in the future is to 
further explore the application of GPU in simulations while 
optimizing the geometric description of detectors to adapt to 
the characteristics of GPU parallel computing. This approach 
will accelerate the processing and analysis of experimental 
data and advance the development of physics. 


Il. METHODOLOGIES 


Industrial 3D software, such as Unity [34] and unreal en- 
gines [35], show great potential for developing detector and 
event visualization tools in HEP experiments. They have been 
applied to event displays, data analyses, and outreach soft- 
ware development in several HEP experiments, including AT- 
LAS [37, 38], BELLE II [39], BESHI [40], and JUNO [41- 
44]. 

However, HEP detectors are usually complex with millions 
of units, making it challenging to construct a 3D detector 
model using industrial 3D software. In the offline software of 
HEP experiments, the detector description may already exist 
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in certain formats used for detector construction in simula- 
tion and reconstruction. As DD4hep has been selected for 
detector description in next-generation HEP experiments, an 
interface for converting detector geometry data from DD4hep 
to 3D modeling in Unity or unreal would highly benefit the 
HEP software community by leveraging potential 3D soft- 
ware. Therefore, we propose a novel method for automat- 
ically converting the DD4hep detector description into the 
well-known FBX format, which can be directly imported into 
3D software to construct the detector model. 


A. Automatic detector geometry conversion 


The automatic conversion of detector description originates 
from the need to maintain geometric consistency across dif- 
ferent applications in HEP offline software. This can be re- 
alized by developing various automatic geometry conversion 
interfaces between different software packages while main- 
taining a single source of detector data. 

In the BESIII experiment, the detector description with 
GDML was used to construct a detector in Geant4 for simula- 
tion through the GDML-Geant4 interface, and in ROOT for 
reconstruction and event display with the GDML-ROOT in- 
terface [18, 45]. In addition, a method for detector conversion 
from GDML to FBX using FreeCAD was proposed to con- 
struct a BESIII detector in Unity [40] for further event-display 
development. Fig. 4 shows the BESIII detector in Unity with 
the detector geometry converted from GDML, which has ex- 
cellent visualization effects. In addition, a tool for directly 
converting geometry from Geant4 to FBX or VRML for- 
mat has been developed in the Belle II experiment for detec- 
tor navigation, physical analysis, and VR applications [39]. 
These interfaces ensure consistency in the detector geome- 
try across simulation, reconstruction, event display, and data 
analysis. Moreover, they save considerable human effort for 
software developers by providing automatic detector conver- 
sion, which enriches the 3D modeling software interface and 
facilitates the development of extended applications. 

As a new-generation detector description technique, 
DD4hep has a similar architecture to that of automatic de- 
tector geometry conversion. DD4hep was developed us- 
ing the ROOT geometry package and has an interface with 
Geant4 detector construction. In principle, DD4hep can be 
converted to FBX using existing conversion interfaces, such 
as the chain of DD4hep-ROOT-GDML-FreeCAD-FBX or 
DD4hep—Geant4—FB X. 

However, these detector description systems have inherent 
differences, which can lead to challenges after multiple steps 
of conversion in a long chain. Furthermore, these conversions 
require the construction of a detector first in ROOT or Geant4 
during program running, which significantly depends on the 
Geant4/ROOT geometry construction packages and can cause 
problems because of different software versions. If a novel 
method for direct DD4hep—FBX conversion can be realized, 
this universal technique would benefit all current and future 
HEP experiments, enabling the development of applications 
for detector visualization, event display, and outreach. 
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Fig. 4. Display of the BESIII detector in Unity with detector geom- 
etry data converted from GDML. 


B. Detector data conversion from DD4hep to FBX 


To develop a method for converting DD4hep to FBX, the 
similarities and differences between their detector construc- 
tion systems should be considered. As shown in Fig. 5, 
DD4hep and FBX have four similar components: 


e Shapes. Dimensions and shapes of the basic solid units 
that form the detector. 


e Rotations/translations. Relative positions between dif- 
ferent solids. 


e Materials. Matter, including atom composition, den- 
sity, and other attributes, from which solids are defined. 


e Geometry hierarchy. Structures of detector unit com- 
positions and their relationships. 


To complete the detector data conversion, all geometric in- 
formation must be extracted from DD4hep, mapped to the 
corresponding parts in FBX, and reorganized in the format of 
FBX definition. Then, it can be imported into a popular in- 
dustry software, such as Unity or Unreal, to construct a 3D 
model of the detectors. 

The FBX file format is available in an ASCII file format, 
facilitating reading and checking. It comprises a nested list 
of nodes arranged in a hierarchy. In this study, nodes are di- 
vided into “Objects” and “Connections.” Information regard- 
ing shapes, materials, and models, which describe shading, 
position, and rotation, is placed in the “Objects” node. The 
“Connections” node describes connections between shapes 
and models, models and models, or materials and models. 
Fig. 6 shows a simplified example of the trapezoid (TRD2) 
shape description in FBX. 

The first step in the conversion is to map the shape descrip- 
tion into the FBX format for all types of standard shapes in 
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Fig. 5. Detector data flow in conversion from DD4hep to FBX. 


Geometry: 549772591104, "Geometry::Trd_shape", "Mesh" { 
Vertices: *24 { 
at -2,+3,-4,2,-3,-4,2,3,-4,-2,3,-4,°6,-5,4,6,-5,4,6,5,4,-6,5,4 
J 
PolygonVertexIndex: *24 { 
a: B23; 25-24, 753; = 57,025 545 Gy 25 2535 95 4H 25 45 9565-8 
} 
GeometryVersion: 124 
LayerElementNormal: © { 
Version: 101 
MappingInformationType: "ByPolygonVertex" 
ReferenceInformationType: "Direct" 
Normals: *72 { 
a: @,0,-1,0,0,-1,0,0,-1,0,9, -1, -0.894427 ,0, -@.447214, -0.894427 , 
O, -0.447214 , -0.894427 ,0, -0.447214 , -B . B94427 ,ð, -0.447214 
,0,0.970143, -0.242536 ,0,0.970143 , -0.242536 ,0,0.970143 , -0 . 242536, 
@,@.970143, -@.242536,0.894427,0, -@.447214,8.894427,@,-0.447214, 
@.894427,@,-@.447214,0.894427,0, -0.447214 ,0 , -0.970143 , -0 . 242536, 
@, -0.970143 , -0.242536 ,0, -0.970143 , -@. 242536,0, -0.970143 , 
-0.242536,0,-@,1,0,-0,1,0,-0,1,0,-0,1 
} 
} 


Fig. 6. Example FBX file for the Trapezoid shape based on the 
polygonal surface description. 


DD4hep. The current detector description systems in the HEP 
software, including Geant4, ROOT, GDML, and DD4hep, 
employ the CSG system, which uses characteristic parame- 
ters to define the shape of a solid. FBX depends on a surface 
definition system that uses a set of polygons with vertices and 
a normal to define the surface of a solid. For example, as 
shown in Fig. 7 (a), to describe a TRD2 shape, which is a 
trapezoid with both the X and Y dimensions varying along 
the Z-axis, the CSG system requires only five parameters: 


e dz, the half-length along the Z-axis; 

e dx, the half-length along x at the surface at -dz; 
e dx2, the half-length along x at the surface at +dz; 
e dyl, the half-length along y at the surface at -dz; 
e dy2, the half-length along y at the surface at +dz. 


To describe the same TRD2 shape, FBX needs to determine 
the coordinates of the eight vertices, the sequence of the ver- 
tices to form a polygon, and the normal direction of every 
polygon to form the surface of the trapezoid, as shown in 


x2 


(a) (b) 
Fig. 7. Visualization of the Trapezoid (TRD2) shape defined with 
DD4hep (left) and FBX (right). 


28 Fig. 7 (b). All this information can be obtained using the 
289 five-dimensional parameters of the TRD2 shape definition in 
290 DD4hep to generate the corresponding FBX description for 
21 TRD2, as shown in Fig. 6. Fig. 7 compares the same 
22 TRD2 shapes from the DD4hep description visualized in 
23 ROOT (left) and FBX description visualized in Unity (right). 
24 Similarly, all the other DD4hep shape information can be 
23 determined and mapped into the FBX description. The CSG 
ze system is convenient for describing standard shapes, whereas 
297 FBX is flexible in describing irregular shapes. Fig. 8 shows 
za Standard basic shapes converted from DD4hep to FBX dis- 
29 played in Unity. Additional composite shapes are converted 
300 in DD4hep using Boolean calculations, including union, sub- 
301 traction, and intersection, as shown in Fig. 9. 


HTA 


(a) Hyperboloid. (b) Box. (c) Cone. 


(d) Paraboloid. (e) Sphere. (£) Tube. 


Fig. 8. Some basic shapes converted from DD4hep to FBX and dis- 
played in Unity. 


32 Second, the transformation information, including transla- 
33 tions and rotations of the volumes, in DD4hep is written into 
34 the “Model” node, which is a sub-node of the “Geometry” 
node in FBX. The transformation information describes the 
3% relative positions for placing a volume within another volume 
307 or the “Mother Volume” in CSG geometry. A volume with 
such placed information attached is termed as a “Placed vol- 
ume” in DD4hep, “Physical volume” in Geant4, or “Model” 


305 


308 
309 


z 


315 


346 


347 


348 


349 


350 


LAY, 


(a) Union. (b) Subtraction. (c) Intersection. 
Fig. 9. Boolean shapes converted from DD4hep to FBX and dis- 
played in Unity, including the union of two tubes (a), the subtraction 


of two trapezoids (b), and the intersection of a box and a sphere (c). 


in FBX. Owing to their similarity, the conversion of the trans- 
formation information from DD4hep to FBX is straightfor- 
ward. 

Third, the material information is extracted from DD4hep 
and written into the “Material” node, which is the sub-node 
of the “Objects” node, in FBX. In DD4hep, the information 
of the materials and shapes is attached to the volume, which 
is also termed as “Logical volume” in Geant4. Therefore, 
the corresponding association between materials and volumes 
must be maintained in FBX. In addition to the basic mate- 
rial information from DD4hep, FBX supports attribute defi- 
nitions, such as texture and reflection, which can be added at 
a later stage. 

Finally, after converting all shape, transformation, and ma- 
terial information, they must be organized in the hierarchy of 
the entire detector tree with their associations defined in FBX. 
A unique index was attached to each geometry, model, and 
material node. Their associations are defined using “connec- 
tions,’ which are determined by the unique indexes between 
any two shapes, transformations, materials, and models that 
are written into the “connections” node in FBX. 

The original HEP detector description in DD4hep format 
comprises the following parts: shapes, materials, positions 
and rotations, detector components (physical node), and de- 
tector hierarchy. After completing the aforementioned four 
steps, the DD4hep detector description is transformed into the 
FBX format, which can be directly read using industrial 3D 
software, such as Unity and Unreal, while retaining detector 
information consistent with that in DD4hep. 

Using the aforementioned method, we proposed a method 
that converted the detector description from DD4hep into the 
FBX format using automated 3D detector construction. The 
accuracy of the detector geometry conversion in each step was 
validated by visualization and comparison at both shape and 
detector levels. With the conversion of 3D detector model- 
ing into FBX, further application development using detector 
geometry in industrial 3D software can be achieved. 


IV. APPLICATIONS 
A. CLIC detector 


The CLIC is a concept for future linear colliders that can 
generate e*e7 collisions at a center-of-mass energy of up to 


(f) 


Fig. 10. Comparison of the CLIC sub-detector VXD with DD4hep 
format displayed in ROOT (left) and with FBX format displayed in 
Unity (right). (a)(b) 3D perspective view, (c)(d) cut view of z — r 
plane, and (e) (f) cut view of x — y plane. 


351 3 TeV. Because DD4hep is designed for the next-generation 
332 HEP experiments, and the CLIC detector description is al- 
353 ready provided in the DD4hep toolkit, the DD4hep—FBX con- 
354 verter should be tested for application in the CLIC detector. 


35 The CLIC experiment requires a detector system with ex- 
ase cellent jet energy and track momentum resolution, highly ef- 
357 ficient flavor tagging, lepton identification capabilities, full 
358 geometrical coverage extending to low polar angles, and tim- 
359 ing resolution in the order of nanoseconds to reject beam- 
3 induced background. The conceptual design of the CLIC de- 
31 tector includes a low-mass all-silicon vertex detector (VXD) 
3æ2 and tracking detector system (TRD), an electromagnetic 
33 calorimeter (ECAL) with silicon pad sensors and tungsten 
34 absorbers, a hadronic calorimeter (HCAL) with scintillating 
3s tiles, a solenoid of 4 T, and a return yoke with an embedded 
3 Muon detector (MUD). 

37 Fig. 10 shows the CLIC subdetector VXD in the DD4hep 
ses. format displayed in ROOT (left) and in FBX format displayed 
39 in Unity (right). A 3D perspective view and two cut views of 
370 the z — r and x — y planes are compared and validated. The 
37 Silicon VXD consists of five layers in the barrel, eight layers 
372 in the endcap, and a carbon fiber support. 

373 Fig. 11 shows the CLIC sub-detector TRD in both 
37⁄4 DD4hep and in FBX formats, displayed in ROOT (left) and 
37s Unity (right)respectively. The TRD consists of five layers in 
376 the barrel, eight layers in the endcap, six layers in the forward, 
377 and support layers. Three types of views are also compared. 
37s Because the FBX format uses polygonal surface description, 
379 the boundaries of every polygon can be observed in the 3D 
380 perspective view of the TRD in this format, as shown in Fig. 
331 11 (b)). 

332 The other sub-detectors, including the solenoid, ECAL, 
333 HCAL, and MUD, of CLIC can be converted from DD4hep to 
384 FBX using the same operation. Their perspective 3D views 


Fig. 11. Comparison of the CLIC sub-detector TRD with DD4hep 
format displayed in ROOT (left) and with FBX format display in 
Unity (right): (a)(b) 3D perspective view, (c)(d) cut view of z — r 
plane, and (e) (f) cut view of x — y plane. 


35 With FBX descriptions are displayed in Unity, as shown in 
386 Fig. 12. While displaying the sub-detectors in Unity, the 
3837 top-world volume and virtual mother volumes should be con- 
sss. Cealed to enable the inner detector units to be easily identified. 
ss9 Moreover, the automatic conversion is advantageous in that 
390 the name of each detector unit is maintained throughout the 
transformation process. Thus, scripts can set the visualiza- 
tion attributes using the name of each detector unit, rendering 
it convenient to develop further applications, such as event 
display. 

35 By combining all the sub-detectors, a complete CLIC de- 
sss tector, comprising the vertex detector (VTX), TRD, ECAL, 
37 HCAL, and MUD sub-detectors from the inside to the out- 
38 Side, are formed. The display of the full CLIC detector, with 
39 the DD4hep format displayed in ROOT and FBX format dis- 
so played in Unity, is shown in Fig. 13. A converter can also 
41 complete the full CLIC detector conversion in a single step 
42 and generate a unified FBX file for subsequent development. 
4o3 Visual scans of the CLIC detector at both the basic detector 
s4 unit level and full detector level from various viewpoints re- 
45 veal no noticeable discrepancies or conflicts between the two 
s formats of the DD4hep and FBX detector descriptions. To 
47 validate the correctness and normal operation of the DD4hep-— 
40s FBX converter, further applications involving additional de- 
4o9 tector conversions are necessary to improve its quality. 
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(a) Solenoid. (b) ECAL. 


(c) HCAL. (d) MUD. 


Fig. 12. CLIC sub-detectors described with FBX and displayed in 
Autodesk FBX viewer. 
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Fig. 13. Comparison of the full CLIC detector with DD4hep for- 
mat displayed in ROOT (a)(c), and with FBX format displayed in 
Unity (b)(d): (a)(b) cut view of the x — y plane and (c) (d) cut view 
of the z — r plane. 
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B. STCF and CEPC sub-detectors 


The STCF [46] is an electron-positron collider, which is 
still in the R&D stage, with a double ring and symmetric 
beam energy. It is designed to operate within a center-of-mass 
energy range of 2 GeV ~7 GeV and has a peak luminosity of 
0.5 x 10?°cm—*s—?, 

The STCF detector comprises an inner tracker, a main drift 
chamber, a ring image Cherenkov detector using micro pat- 
tern gaseous detector for photon detection, a DIRC-like high- 
resolution TOF detector (DTOF), and a crystal ECAL, all of 
which are enclosed in a superconducting solenoidal magnet 
providing a 1.0-T magnetic field. The solenoid was supported 
by an octagonal flux-return yoke with resistive plate counter 
MUDs interleaved with steel. 

Similarly, the CEPC [22] detector is an electron-positron 
collider in the R&D stage. The collider with a circumfer- 
ence of 100 km was designed to operate at a center-of-mass of 
240 GeV (Higgs factory), approximately 91.2 GeV (Z factory 
or Z pole), and approximately 160 GeV (WW threshold scan). 
It contains a vertex detector (VTX), a silicon inner tracker and 
silicon external tracker, forward tracking detector and endcap 
tracking detector components, a time projection chamber, an 
ECAL, a hadronic calorimeter (HCAL), a solenoid of 3 Tesla, 
and a return yoke embedded with MUDs. 

The STCF and CEPC offline software are under develop- 
ment, and the DD4hep toolkit has been used in both exper- 
iments for detector description. Because of the complexity 
of both detectors and their development stage, we chose only 
one sub-detector in each experiment to demonstrate the fea- 
sibility of applying the DD4hep—FBX converter in STCF and 
CEPC experiments. 

The STCF DTOF and CEPC ECAL sub-detectors were 
converted from DD4hep to FBX. The DTOF sub-detector in 
STCF is a high-resolution detector of internal total-reflected 
Cherenkov light in the endcap. A comparison of the DTOF 
with the DD4hep format displayed in ROOT and FBX format 
displayed in Unity is shown in Fig. 14. The ECAL sub- 
detector in the CEPC is a highly granular silicon—tungsten 
calorimeter, which can be instrumented to provide precise 
time measurements with a 50-ps or higher resolution. A com- 
parison of ECAL in the CEPC with the DD4hep format dis- 
played in ROOT and with FBX format displayed in Unity is 
shown in Fig. 15. 


C. Performance 


The performance of the DD4hep—FBX converter was eval- 
uated in the above-mentioned applications. In the CLIC 
DD4hep detector, 35,107 detector elements, 11,640 repli- 
cated volumes, and 130,882 placed volumes were observed. 
The conversion was performed on a computer with an Intel 
Core 17-13700H CPU (2.4 GHz) with 16-GB memory. Ap- 
proximately 9 s was required to convert the full CLIC detec- 
tor from DD4hep to FBX, occupying approximately 163.5- 
MB memory at its peak, using the Valgrind [47] toolkit for 
analysis (Fig. 16). 
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Fig. 14. Comparison of the STCF DTOF sub-detector with DD4hep 
format displayed in ROOT (a) and with FBX format displayed in 
Unity (b). 


(a) (b) 


Fig. 15. Comparison of the CEPC ECAL sub-detector with DD4hep 
format displayed in ROOT (a) and with FBX format displayed in 
Unity (b). 


Memory heap size 


Fig. 16. Memory usage during conversion of the full CLIC detec- 
tor from DD4hep to FBX. Purple and blue parts are used to convert 
shapes to polygons. The cyan part is used to write the FBX nodes to 
the file on disk. The yellow part is the vector that stores the infor- 
mation of all shapes, volumes, and locations. 


The total size of the CLIC detector FBX file after conver- 
sion from DD4hep was 148.8 MB with 404,306 polygons, 
which corresponded to the precision of the polygon approx- 
imation of the curved surface. The time and memory con- 
sumption for each CLIC sub-detector, as well as the STCF 
DTOF and CEPC ECAL subdetectors, are summarized and 
compared in Table 1. 

Because of the complex CLIC full-detector geometry and 
large polygon numbers in FBX, more than 2 h is required to 


Table 1. Performance and computing resources consumption in de- 
tector conversion. 
Detector Conversion time (s) Memory (MB) Numbers of polygons FBX size (MB) 


CLIC VXD 0.28 92.0 22,008 1.9 
CLIC TRD 6.07 143.9 30,384 107.9 
CLIC ECAL 0.33 93.0 3,300 2.9 
CLIC HCAL 0.39 94.5 5,100 4.0 
CLIC MUD 0.33 93.0 4,912 3.0 
Full CLIC 7.46 163.5 404,306 148.8 
STCF DTOF 0.49 92.7 188 6.4 
CEPC ECAL 28.28 358.5 46,526 459.0 


473 import the CLIC FBX file into Unity. Fortunately, the im- 
474 port process from FBX to Unity is a one-time operation. Af- 
47s ter importing the FBX file and saving it as a Unity project, 
476 approximately 30 s is required to reopen the project. Never- 
477 theless, further improvements are required for developing the 
47a DD4hep-FBX or similar converters in the future. 


479 D. Further application development 


4s0 With the HEP detector description converted into the FBX 
4s1 format, FBX files can be directly read by the industrial 3D 
4s2 SOftware to further develop applications, such as event display 
483 tools, VR or AR programs with excellent visual effects, and 
484 cross-platform deployment. 

48s Unity is a well-known video and game production en- 
4ss gine. Recently, it has been used in HEP experiments, such 
487 as the Cross-platform Atlas Multimedia Educational Lab for 
ass Interactive Analysis (CAMELIA) [37, 48] in the ATLAS 
489 experiment and Event Live Animation with Unity for Neu- 
4w trino Analysis (ELAINA) [41] in the JUNO experiment, for 
41 event displays. In both programs, the detectors were man- 
42 ually constructed in Unity, rendering them one of the most 
43 time-consuming parts of the program development. With the 
44 DD4hep—FBX converter, detector construction in Unity will 
49 be convenient for future HEP experiments. 

4s Unreal Engine is another potential and versatile industrial 
497 Software that can create 3D content for applications such as 
48 games, films, TV, architecture, and automobiles. Both Unity 
499 and Unreal are potential tools for developing VR and AR 
so applications with strong hardware support. Some VR appli- 
so cations have been realized in currently running HEP experi- 
soe ments, such as ATLASrift [49], BelleII VR [39], and VR tours 
so3 for experiments at CERN [50]. VR and AR programs provide 
soa sufficient experience for understanding HEP detectors and ex- 
so periments, significantly contributing to detector design, data 
sos analysis, and outreach. The DD4hep—FBX converter can as- 
so7 sist and accelerate the development of these programs owing 
sos to its automatic and fast detector conversion function. 


509 V. SUMMARY 


sio In the offline software development of the next-generation 
s51 HEP experiments, the HEP software community has adopted 
s512 DD4hep as a common technique for detector description. 
sis However, in contrast to commonly used 3D modeling formats 
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such as FBX, the DD4hep format cannot be directly imported 
by most well-known 3D modeling and visualization software 
from the industry. Consequently, this potential industrial soft- 
ware cannot easily be used for application developments in 
HEP experiments. 

To address this limitation, we introduced a novel method 
for converting detector description from DD4hep to the FBX 
format. A full CLIC detector and several sub-detectors of 
the STCF and CEPC were tested to demonstrate the feasi- 
bility of this method. Using the automatic conversion in- 
terface, we provided convenience and potential for leverag- 
ing industrial 3D software in developing detector geometry 
and visualization-related applications, such as detector de- 
sign, simulation, event display, data monitoring, and out- 
reach, with advanced visualization techniques in future HEP 
experiments. 
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